Git 的介绍
1. Git 和 GitHub 的关系
- Git 是代码历史版本控制器
- GitHub 是代码托管中心
2. Git 的介绍
- Git 是 Linux 的开发者为了维护Linux而开发出来的,所以 Git 支持 Linux 的命令
3. Git 结构
- 工作区:写代码的地方
- 暂存区:准备提交到本地库的地方
- 本地库:存储历史的版本
4. Git 安装
- 去 git 官网下载安装包,然后进行傻瓜式安装
Git 的操作
- 在需要进行 git 版本管理的项目目录下,右键选择 Git Bash Here 对该项目进行 git 的版本管理


Git 命令步骤

技巧: 可以使用tab键补全命令
1. 本地库的初始化
git init
2. 设置签名
- 一般用作于标记谁修改了本次历史记录
- 局部设置 -> 作用域该文件夹
git config user.name "Kevin"
git config user.email "2256426349@qq.com"
- 全局设置 -> 作用域本电脑全局设置 作用域本电脑 【推荐】
git config --global user.name "Kevin"
git config --global user.email "2256426349@qq.com"
3. 查看本地库的状态
git status
4. 将项目添加到 暂存区
- 将项目的指定文件添加到暂存区
git add 文件名.后缀
- 将项目的所有文件添加到暂存区
- . -> 将项目中的所有文件添加到暂存区中,并且会根据 .gitignore 文件进行过滤 【推荐】
git add .
- * -> 将项目中的所有文件添加到暂存区中,忽略 .gitignore 文件
git add *
5. 将项目移除出 暂存区
- 只移除出暂存区,且不删除文件【推荐】
- 将项目的指定文件移除出暂存区
git rm --cached 文件名.后缀
- 将项目的所有文件移除出暂存区
git rm -r --cached .
- 移除出暂存区,并且删除文件
- 将项目的指定文件移除出暂存区,并且删除文件
git rm -f 文件名.后缀
- 将项目的所有文件移除出暂存区,并且删除文件
git rm -rf .
6. 将 暂存区 的文件提交到 本地库
- 注意: 将暂存区的内容添加到本地库后,暂存区的内容会清空,且使用 git status 会提示没有需要添加的内容(除非: 项目的目录结构或文件进行了修改)
- 不用进入 vim 编辑器设置备注【推荐】
- 将暂存区中的指定文件添加到本地库中
git commit -m '备注内容' 文件名.后缀
- 将暂存区中的所有文件添加到本地库中
git commit -m '备注内容'
- 需要进入 vim 编辑器设置备注
- 将暂存区中的指定文件添加到本地库中
git commit 文件名.后缀
- 将暂存区中的所有文件添加到本地库中
git commit
- 进入 vim 编辑器设置本次提交的历史版本备注
- :set nu 显示行号
- 点击 i 进入输入模式 esc 退出输入模式
- :wq 退出本次操作

- 直接绕过暂存区,将文件提交到本地库中【不推荐使用】
- 将项目的指定文件添加到本地库中
git commit -a -m '备注内容' 文件名.后缀
- 将项目的所有文件添加到本地库中
git commit -a -m '备注内容'
6. 当项目的目录结构或文件被再次修改的时候

- git add 文件名 或 git add . 提交到暂存区,再通过 git commit 文件名 或 git commit 提交到本地库中
历史版本的操作

1. 查看提交的历史版本
- 查看所有分支的操作记录【推荐】
- 注意: 历史版本回退后,仍然可以看到所有的历史版本记录
git reflog

- 查看当前分支的提交记录
- 注意: 历史版本回退后,使用 git log 看不到回退版本号之后的历史版本记录
- 当数据过多的时候会进入多屏模式
- 多屏控制方式:
- 空格 -> 下一页
- b -> 上一页
- q -> 退出
git log

- 查看当前分支的提交记录 -> 以精简模式显示
- 注意: 历史版本回退后,使用 git log 看不到回退版本号之后的历史版本记录
git log --pretty=oneline

- 查看当前分支的提交记录 -> 以精简模式显示,且历史版本号也是以精简模式显示
- 注意: 历史版本回退后,使用 git log 看不到回退版本号之后的历史版本记录
git log --oneline

2. 历史版本的前进与后退(即:将当前项目回退到之前的状态)
- git reset 参数
- --hard -> 本地库和暂存区域的历史和记录会被修改文件内容也会被修改
- --soft -> 本地库的历史记录会进行修改 但是文件内容并没有
- --mixed -> 本地库和暂存区域的历史记录会被修改 但是文件内容没有修改
- 基于历史版本号进行操作【推荐】
git reset --hard 历史版本号

- 使用 ^ 符号进行操作(只能后退不能前进)
- 一个 ^ 代表一步
git reset --hard HEAD^^ # 从当前之前回退2步,一个 ^ 代表一步

- 使用 ~ 符号进行操作(只能后退不能前进)
git reset --hard HEAD~2 # 从当前之前回退2步

- 例子: 删除文件并找回
- 前提:删除前,文件存在时状态提交到了本地库
- 操作:git reset --hard 历史版本号
比较文件
1. 工作区与本地库进行比较
- 注意: 当文件被修改后提交到了暂存区后,使用以下命令进行比较是没有任何效果的
- 比较工作区的所有文件
git diff

- 比较工作区的指定文件
git diff 文件名.后缀

2. 工作区与本地库最新的历史版本进行比较
git diff HEAD 文件名.后缀

3. 工作区与本地库某个历史版本进行比较
git diff HEAD^^ 文件名.后缀

4. 工作区与本地库某个历史版本进行比较
git diff -w 历史版本号 文件名.后缀

分支
分支的介绍
1. 什么是分支?
- 在历史版本控制过程中,使用多条线同时推进多个任务

2. 什么是分支?
- 同时并行推进多个功能开发,提高开发效率
- 各个分支在开发过程中,如果某个分支开发失败,不会对其他分支有任何影响。失败的分支删除重新开始即可
3.master 分支 和 dev 分支
- 说明: 在个人进行开发软件开发的时候,使用git的分支可以很好的进行管理自己工程进度.使用master和dev两个分支策略可以更好的控制开发版本和稳定版本
- master 分支: 一般用于存放项目的稳定版本
- 注意: 不要在 master 分支上直接修改代码
- 如果 master 分支上的项目出现 bug,且此时已经有了 dev 的分支在开发别的功能,那么在 master 分支上创建一个新的分支修改 bug,当 bug 修复后再跟 master 分支进行合并即可,当合并完后最后删除该修改 bug 的分支
- dev 分支: 一般用于存放项目的开发版本
4.分支的名称说明
- master 分支: 一般用于存放项目的稳定版本,且不要在 master 分支上直接修改代码
- dev 分支: 一般用于存放项目的开发版本
- review 分支: 一般用于审核新员工或员工的代码是否有问题,如果没有问题再合并到 dev 分支上 -> 注意: 这条分支看公司的需求
- Yeung 员工分支: 因为每位员工开发的功能都不一样,所以需要有不同的员工分支,当功能开发完后再合并到 review 或 dev 分支上
- Kevin 员工分支: 因为每位员工开发的功能都不一样,所以需要有不同的员工分支,当功能开发完后再合并到 review 或 dev 分支上
- bug 分支: 一般用于临时修复 master 分支项目的 bug
分支的操作
1. 查看所有分支
- 精简查看
git branch

- 详细查看
git branch -v

2. 创建分支
- 创建分支的前提: 必须要有东西提交到本地库,否则就会报一下错误

- 拷贝当前分支的所有项目内容到新的分支上
git branch 新的分支名
3. 删除分支
- 注意: 在删除分支的时候不能删除当前的分支(即: 不能在当前分支删除当前分支)
- 在删除前检查merge状态
git branch -d 分支名
- 直接删除(强制删除)
git branch -D 分支名 # 简写
# 等同于
git branch --delete --force 分支名
4. 切换分支
git checkout 分支名

5. 合并分支
- 注意: 如果 newbranch 分支 想与 master 分支 进行合并,那么要先将分支切换为 master 分支,然后在进行合并
- 第一步: 切换到接受修改的分支(被合并,增加新内容的分支)上
git checkout 被合并的分支名
- 第二步: 执行 merge 命令
git merge 有新内容分支名

- 合并前

- 合并后

6. 解决合并分支时发生的冲突
- 发生冲突的前提: 如果两个分支都改了相同的地方且内容都不一致并且已提交到本地库就会发生冲突

- 被合并分支的文件会变成以下内容(冲突的表现)

- 修改冲突部分

- 使用 git add . 或 git add 文件名.后缀 将修改后的文件添加到暂存区中

- 使用 git commit 或 git commit -m '备注内容' 将暂存区的内容提交到本地库然后会自动结束手动合并模式
- 注意: 这里不能带文件名 不能使用 git commit 文件名.后缀 或 git commit -m '备注内容' 文件名.后缀

7. 查看所有冲突文件
git diff --name-only --diff-filter=U

tag 项目版本
注意: 这里的版本指的是项目的版本,而不是上面的历史版本
1. 什么是 tag
- tag 是 Git 版本库的一个快照,指向某个 commit 的指针
- 通俗理解:
- tag 就是一个只读的 branch,一般为每一个可发布的项目历史记录打一个项目版本
- tag 就相当于一条历史版本记录
2. 使用tag 的好处
- tag 的存在,是因为我们需要这种标记的功能。目前的项目开发中,当发布项目版本时 tag 就派上用场了。例如 v1.0.1,v1.0.2…
- git 提供了 tag 的增删改查一系列操作
3. tag 和 branch 的区别
- tag 对应某次 commit, 是一个点,是不可移动的
- branch 对应一系列 commit,是很多点连成的一根线,有一个HEAD 指针,是可以依靠 HEAD 指针移动的
- 两者的区别决定了使用方式,改动代码用 branch,不改动只查看用 tag
- 通俗理解: tag 就是一个只读的 branch,一般为每一个可发布的项目历史记录打一个项目版本
4. tag 的相关命令
- 创建项目版本
- 对当前的历史记录标记一个项目版本
git tag -a 项目版本号 -m '版本介绍'

- 查看指定的项目版本
git show 项目版本号

- 查看本地库的所有项目版本
git tag -n

- 模糊匹配查看项目版本
git tag -l 'v1.*'

- 删除项目版本
git tag -d 项目版本号

- 切换项目版本
git checkout 项目版本号

- 推送本地库中的所有项目版本到远程库
git push 远程库网址别名 --tags

- 推送本地库中的指定项目版本到远程库
git push origin 项目版本号

- 删除远程库的指定项目版本
git push 远程库网址别名 -d 项目版本号

- 拉取远程库的指定项目版本
git fetch 远程库网址别名 tag 项目版本号

- 模糊拉取远程库的项目版本
git fetch 远程库网址别名 tag v*

5. tag 的使用场景
- tag 和 branch 的相互配合使用,有时候起到非常方便的效果,例如 已经发布了 v1.0 v2.0 v3.0 三个项目版本,这个时候,我突然想不改现有代码的前提下,在 v2.0 的基础上加个新功能,作为 v4.0 发布。就可以检出 v2.0 的代码作为一个 branch ,然后作为开发分支
- 切换到 v2.0 的版本
git checkout v2.0

- 将 v2.0 版本的项目内容复制到新的分支上
git switch -c 新的分支名

- 在新的分支上开发 v4.0 版本的功能